-
-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Semver-major changes #173
base: main
Are you sure you want to change the base?
Semver-major changes #173
Conversation
Importing a fresh copy of graceful-fs then using `require('fs').close` would only initiate retry of the queue from the first copy of graceful-fs, so needed retries associated with subsequent instances of graceful-fs would not be executed.
Some changes in the previous commit are not needed in v4.x which will never be tested under nyc. The only thing needed is the ability for the next version of graceful-fs to reset fs.close / fs.closeSync.
This was for an issue with versions of node.js that are EOL. Node.js commits which fixed this issue: * v4.6.2+ - nodejs/node@3d6f107a2f * v6.8.0+ - nodejs/node@07d97f4f3e * v7.0.0+ - nodejs/node@3d6f107a2f Also remove associated testing.
Properly handle DEP0013 in ENFILE/EMFILE patched functions depending on node.js version.
* Add autoClose support to WriteStream.open * Prevent accidental monkey-patching of fs.*Stream
Properly handle DEP0013 in patched fs.close.
Process callback argument to ensure proper handling if missing.
* Create windows-rename-polyfill.js * Eliminate process.env.GRACEFUL_FS_PLATFORM * Modernize windows-rename-polyfill test
* Prefer const * Space before function parentheses * Remove unused args
So far the only reaction to nodejs/node#29109 has been negative. I'm not sure it's a great idea to publish the |
Additionally I'd like to see where things go with some active PR's against node.js fs streams. In particular I think graceful-fs@5.0.0 should conditionally use whatever options are eventually provided by nodejs/node#29083, the less we override the better. |
* Avoid process.binding * Monkey-patch promises FileHandle.close to call retry * Do not use promisify * Eliminate delay on first open
"glob": "^7.1.4", | ||
"import-fresh": "^3.1.0", | ||
"nyc": "^14.1.1", | ||
"rimraf": "^2.6.3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to be up to rimraf@3.0.0, as I proposed in PR #177
Any news on this one? |
@brodybits on hold for nodejs/node#29083. I think the last CI blocker was just fixed in the PR so hopefully that can be merged soon. Once it's merged and (hopefully) backported to 13.x I'll be updating here to use that feature when possible and will refresh latest versions of all dependencies. |
FYI nodejs/node#29083 is now merged. It was merged as semver-minor and I believe it should be included in node 13.6.0 or soon thereafter. |
I would favor dropping Node.js 8 support since it is near EOL. |
@ronag thanks for the update. I'll update this once fs stream overrides are in a release (I will need a check against @brodybits node.js support will be up to @isaacs. Worth noting the detection of |
Thanks @coreyfarrell. My idea was that dropping Node.js 8 would reduce burden of future updates for the next 1-2 years or so. Just an idea:) |
Why does it take so long to merge this? |
I can break this into smaller PR's if that makes it easier to review. This enables 100% coverage, adds osx to the travis config (lutimes polyfills can only be tested on osx). Note the first 3 commits in this PR are already submitted to #169.
One thing I'm not thrilled about is how
fs.promises.open
is implemented. The first call tofs.promises.open
may be slightly delayed while the system finishes patching that function. Specifically we need the native C++FileHandle
and the JavaScriptclass FileHandle
fromlib/internal/fs/promises.js
. The native C++FileHandle
is acquired through theprocess.binding('fs').FileHandle
which is deprecated. The only way to getclass FileHandle
is by calling the originalawait fs.promises.open
and finding the constructor of the result. Access to the native C++FileHandle
is required to support automagic closing of unclosed fd's on garbage collection. Access to the JSclass FileHandle
is required to allow us to extend the base class, otherwise we would have to reimplement all functions and this would potentially have other negative effects.Fixes #152
Fixes #160
Fixes #167
Fixes #170
Breaking Changes
Features
require('graceful-fs').promises
accessesfs.promises
so in node.js 10 it will trigger the experimental feature warning.Fixes
autoClose: false
in WriteStream.openready
event upon stream openRefractors